1. Field of the Invention
The present invention relates generally to industrial robot control systems, and, in particular, to a coordinate system for controlling an industrial robot.
2. Description of the Related Art
In general, in the descriptions that follow, we will italicize the first occurrence of each special term of art which should be familiar to those skilled in the art of robot control systems. In addition, when we first introduce a term that we believe to be new or that we will use in a context that we believe to be new, we will bold the term and provide the definition that we intend to apply to that term. In addition, throughout this description, we will sometimes use the terms assert and negate when referring to the rendering of a signal, signal flag, status bit, or similar apparatus into its logically true or logically false state, respectively, and the term toggle to indicate the logical inversion of a signal from one logical state to the other. Alternatively, we may refer to the mutually exclusive boolean states as logic_0 and logic_1. Of course, as is well known, consistent system operation can be obtained by reversing the logic sense of all such signals, such that signals described herein as logically true become logically false and vice versa. Furthermore, it is of no relevance in such systems which specific voltage levels are selected to represent each of the logic states.
Robot programming methodologies have not changed much since the dawn of the industrial robot some 40 years ago. The most commonly used technique allows the programming of the robotic task by recording positions of interest, and then developing an application program that moves the robot through these positions of interest based on the application logic. Some improvements have been made in this technique, with primary improvement in a graphical interface to specify application logic. Nevertheless, moving the physical robot to positions of interest is still needed in order to record positions of interest. The following paragraphs describe the commonly used methods for this purpose:
Teach Pendant Based:
As illustrated generally in FIG. 1, the most prevalent method involves moving of the physical robot 100 through an operator interface 102 (commonly referred to a teach pendant in industrial robot terminology) that allows the operator to command motion of each joint axis of the multi-axis robot 100. Various choices are available for the axes of motion based on the coordinate frame selected by the operator. In general, known, prior art operator interfaces include the following coordinate frames, several of which are illustrated in FIG. 1:                Axis (Joint) Coordinate Frame: In the axis or joint coordinate frame 104 illustrated in FIG. 1b, the motion of each joint axis of the robot 100 is controlled with respect to positive and negative directions. This approach may pose a non-trivial challenge to a new operator, since, from the perspective of the operator, it is not always obvious which way is positive or negative with respect to the robot. We submit that it may be more intuitive for an untrained operator to visualize robot movement relative to the operator as requiring either clockwise or counter-clockwise rotation, or, alternatively, as requiring rotation to the left or rotation to the right.        Note: for convenience of reference, we may, from time to time, in the following disclosure, refer to the several coordinate frames of reference simply as frames, e.g., we may refer to the “axis frame” rather than use the full “axis coordinate frame”.        Robot Coordinate Frame: In the robot coordinate frame 104b illustrated in FIG. 1a, the robot 100 is installed with the coordinate frame at the origin of the robot aligned with a given world frame 104c (also illustrated in FIG. 1a). Motion of the robot tool (not shown) is controlled by directing it to move along the X, Y, or Z direction relative to a tool center point (“TCP”) or to rotate the tool about the X, Y, or Z directions relative to the TCP. The challenge again is that to a new operator the orientation of the X, Y, and Z directions with respect to the TCP are not always obvious.        TCP Coordinate Frame: In the TCP coordinate frame 104d illustrated in FIG. 1a, coordinates are generally determined with respect to the tool mounting plate 106. As is known, the tool mounting plate 106 is the mechanical part of the robot 100 to which an end-effector (such as a gripper) is attached. By selecting motion in the TCP frame, an operator can move the tool of the robot along the X, Y, and Z direction of the TCP frame. Similarly, the operator can also rotate the tool about the X, Y, and Z directions of the TCP frame. Again, the challenge is that the orientation (which way the X, Y, and Z are pointing) of the TCP frame is not always obvious to an operator who is looking at the robot.        User Coordinate Frame: In the user coordinate frame 104e illustrated in FIG. 1a, location coordinates are normally associated with an object in the robot workspace 108. By selecting motion in a given user frame, an operator can move the tool of the robot 100 along the X, Y, and Z direction of the user frame. Similarly, the operator can also rotate the tool about the X, Y, and Z directions of the user frame. Again, the challenge is that the orientation (which way the X, Y, and Z are pointing) of the user frame is not obvious to an operator who is looking at the robot within the workspace.        
Offline Teaching:
Offline teaching is a technique, somewhat analogous to the teach pendant method, that uses a virtual robot (comprised of a 3Dimensional (“3D”) model or simulacra of the robot and, possibly, the other items in the robot workcell) instead of a physical robot. One such system is disclosed in the Related Patent. Some of these virtual environments have integrated computer-aided design capabilities, and allow the operator to point-and-click on a position of interest, thereby causing the simulacra to move to that point. This feature reduces the manual effort required to jog (or drive) the robot to the intended position in 3D space.
Sensor Driven:
Another known method for programming a robot involves limited teaching of positions, and then using real-time sensor feedback to identify the target position to which the robot needs to move. Usually, this target position is identified using a computer vision system that is programmed, first, to identify the target workpiece, and, then, to return output target position coordinates to which the robot is to move. This reduces the teaching effort, but transfers the effort to the programming and calibration of the vision system. The application logic of how the robot moves to the target position (e.g., the path it takes, the speed at which it moves, etc.) still has to be specified by the application developer.
Lead-Through Teaching:
In general, lead-through teaching requires the operator manually to move the robot through a series of specific positions, typically by grasping its end-effector and moving it through each of the tasks it is supposed to accomplish. Simultaneously, application logic is monitoring the movements and positions, and recording the sequence for later playback during normal operation. As is known, this technique can be used to teach the path the robot has to follow, as well as the several specific positions and tool orientations, and, often, some application logic. However, this technique has not seen wide acceptance due to safety concerns (as the robot has to be powered through this process) and also due to size discrepancy between the human operator and a robot that may be significantly larger than the operator. Notwithstanding, one advantage of this technique is that the operator can not only teach the path, the positions and the orientations, but can also teach the resistive force that the robot needs to apply to the environment when contact is made.
Examples of contemporary robot control systems that implement one or more of the above approaches include the following:
1. ABB (Switzerland).                Flex Pendant, see:        1.1. ABB MultiMove functionality.pdf;        1.2. Datasheet Int PLC ROBO190EN_A;        1.3. IRC5 datasheet PR10258 EN_R13.pdf;        1.4. ROBO236EN_A IRC5_LR.pdf;        1.5. ROBO251EN_A.pdf;        1.6. new.abb.com/products/robotics/controllers/irc5; and        1.7. www05.abb.com/global/scot/scot241.nsf/veritydisplay/b5749ff3daf2a2e7c1257746004ebb1d/$file/Teach%20Pendant.wmv;        1.8. This technology allows the operator to jog the robot using a joystick integrated into the teach pendant, with the angle of displacement of the joystick controlling the speed of movement of the robot. However, the direction of motion of the robot depends only on the direction of movement of the joystick relative to the teach pendent, per se, and this relationship does not change as a function of the position of the pendant+operator relative to the robot, i.e., the relationship between the joystick movements and the robot's jog directions are fixed.        
2. gomtec GmbH (Germany).                roboCommander, see:        2.1. www/gomtec.de/gb/lightweight-robotics/components/robocommander.html; and        2.2. www/gomtec.de/gb/lightweight-robotics/videos/teaching/html;        2.3. While this lead-through teaching approach is intuitive to the operator, it is not generally considered safe for the operator physically to be near robots or to manually operate large robots (however, we note that this may be solved using the latest safety technologies and collaborative robot concepts). A second issue is that getting precise movements is usually difficult and cumbersome with this approach.        
3. KUKA AG (Austria).                SmartPad, see:        3.1. www.kuka-robotics.com/en/products/controllers;        3.2. www.kuka-robotics.com/en/products/controllers/smartPAD/start.html; and        3.3. www.youtube.com/watch?v=4gDjgomANC4;        3.4. This technology allows jogging the robot using a haptic 6D mouse integrated into the teach pendant; however, the resulting direction of the robot's motion does not appear to be relative to the position of the operator with respect to the robot, i.e., the relationship between the mouse movements and the robot's jog directions are fixed.        LBR iiwa, see:        3.5. www.youtube.com/watch?v=r7gU74Yv9Es.        3.6. Our comments with respect to Example 2, above, are pertinent here as well.        
4. KEBA AG (Austria).                KeTop T10 directMove, see:        4.1. KeTop_T10_Datenblatt_E_mail.pdf;        4.2. KeTop_T10_Zusatzbroschuere_E_01.pdf; and        4.3. www.keba.com/en/industrial-automation/kemobile-mobile-operation/products/ketop-t10-directmove;        4.4. This technology integrates into the teach pendant an Inertial Measurement Unit (IMU) to detect in 3D space the orientation of the pendant. In addition, as in Example 1, above, a joystick is provided to allow the operator to initiate jog commands to the robot; however, these references make clear that the movements of the joystick are interpreted by the controller relative to the orientation of the pendant with respect to the downward force of gravity, e.g., the floor of the workcell. Unfortunately, what is NOT made clear in these documents (or any other materials that we have been able to identify) is whether or not the controller factors in (or even has access to data sufficient to determine) the position of the pendant/operator relative to the robot's frame of reference.        
5. Robotiq (Canada).                robotCommander, see:        5.1. RoboCommanderRing.pdf; and        5.2. blog.robotiq.com/bid/68640/Teaching-Welding-Robots-by-Demonstration-vs-Teach-Pendant-Programming;        5.3. Our comments with respect to Example, above, are pertinent here as well.        
6. Universal Robots A/S (Denmark).                Polyscope, see:        6.1. Software_Manual_en_US.pdf (“Polyscope Manual”);        6.2. The Polyscope graphical user interface for Universal Robots' UR5 and UR10 robots employs screens that display a 3D model (i.e., a simulacra) of the robot, and arrows that enable a user to move the robot by pressing the arrows. (See Section 11.1 on page 23 of the Polyscope Manual.) It is also possible for an operator to physically grab the robot arm and pull it to where the operator wants it to be. (See, Section 11.1.5 on page 24 in the Polyscope Manual.) However, even though the Polyscope system displays a 3D model of the robot, the system requires the user to manually reorient the 3D model using controls on the screen so that the viewing angle of the 3D model substantially conforms to the operator's view of the robot. (See Section 11.1.1 in page 23 of the Polyscope Manual.)N.B.: copies of all of the above references, including the videos, are submitted herewith, and each is expressly incorporated herein by reference.        
We submit that what is needed is an improved method for robot programming that encompasses the capabilities of the most prevalent method, i.e., the Teach Pendant Based (see, above), while simplifying this method by using a new set of coordinate frames for commanding the motion of the robot. In particular, we submit this new coordinate frame should be more intuitive to the operator, and substantially reduce the need for the operator to understand geometric coordinate frames and their respective directions. Further, we submit that such a method and apparatus should provide performance generally comparable to the best prior art techniques but more efficiently than known implementations of such prior art techniques.